並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 87件

新着順 人気順

infraの検索結果1 - 40 件 / 87件

  • DMARC をなめるな - 弁護士ドットコム株式会社 Creators’ blog

    Gmailが「メール送信者のガイドライン」を改訂し、なりすましメールへの対策を強化する旨を発表しています。今までは原則、なりすましメール対策の有無にかかわらず、メールはいちおうは届いていました。しかし今後は、なりすましとみなされたメールは届かなくなる方向に向かいつつあります。 なりすましメールとみなされないようにするために、メール送信者には、「メール送信ドメイン認証」への対応が求められます。メール送信ドメイン認証の技術には、主に以下の3つがあります。 SPF: Sender Policy Framework (RFC 7208) DKIM: DomainKeys Identified Mail (RFC 6376) DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) SPFは従来

      DMARC をなめるな - 弁護士ドットコム株式会社 Creators’ blog
    • 路線バスに乗るならせめてちょっとは準備してくれ

      こないだ路線バスに乗ったら、大学生くらいの若者が降り際の運賃支払いでもたついて運転手を困らせていた。 運転手さんも若者のあまりの鈍臭さにイラついてちょっとキツい口調になってしまって、若者は憮然としていた。 バスを降りた若者はすぐにスマホでバスの写真を撮ったりしていたので、「バスの運転手の対応がひどかった」とかなんとか、SNSにでも書き込むんだろう。 だかな若者よ、お前も路線バスに乗るならせめてちょっとは準備してくれ。真横で見てたけど、やってること無茶苦茶だったじゃねーか。 予備知識ゼロで乗ってきて勘で突破できるほど甘い乗り物じゃねーわ。 ここからはボーッと生きてる全国民に向けて言う。 路線バスの利用方法が多少複雑なのはわかる。難しいよな。 でも、そこに不安があるならPASMOとかSuicaを使ってくれ。交通系ICならチャージされてさえいればバカでも簡単に乗れる。 いま半導体不足の影響で物理

        路線バスに乗るならせめてちょっとは準備してくれ
      • ITに強いはずのハイテク企業で、1億人超の個人情報が流出…… 「新技術こそ優れている」という思い込みが招いた大規模事件

        連日さまざまなサイバーセキュリティ犯罪のニュースが報じられる中、いまだに日本のセキュリティレベルは高いとは言えない状況にあります。一方で、企業がサイバーセキュリティ対策を進める上では、人材不足や経営層の意識・関心、コスト、導入による利便性の低下など、さまざまな壁が立ちはだかっています。 そこで今回は、株式会社網屋が主催する「Security BLAZE 2023」より、サイバーセキュリティのエキスパートによる講演をお届けします。本記事では、米金融大手で1億人以上の個人情報が漏えいした事件の背景をひもときながら、問題点とセキュリティ対策のポイントを解説します。 Webセキュリティの第一人者が語る、個人情報流出事件の裏側 徳丸浩氏:ただいまご紹介いただきました、EGセキュアソリューションズの徳丸でございます。本日は「米国金融機関を襲った個人情報大規模流出事件の真相」というテーマでお話をさせてい

          ITに強いはずのハイテク企業で、1億人超の個人情報が流出…… 「新技術こそ優れている」という思い込みが招いた大規模事件
        • 本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita

          この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の4日目です。年末進行、いかがお過ごしでしょうか?みなさま無事に仕事が納まることを願っております… 新人インフラエンジニアが、本番ウェブサーバー60台のホスト名を全部 cat にしてしまった話について、ここに供養させていただきたいと思います 背景 おそらく今から7年くらい前、インフラエンジニアとして転職してきて1年ほどが経ち、本番環境での作業もこなれてきたなというバッチリのタイミングで事を起こしてしまいました。サーバーは CentOS 6 だったと思います。 職場としてはまだまだベンチャー感にあふれ大きな裁量が与えられスピード感のある環境ながら、サービスの登録ユーザー数は1,000万を超え、本番環境の規模としては既になかなかの大きさがあり、ウェブサーバーだけでも60台くらいあったと思います。ひと山につき

            本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita
          • ソフトウェアはなぜバージョンアップしなければならないのか - Qiita

            はじめに 社内インフラの運用担当者にとってソフトウェアのバージョンアップは地味な割に大変な業務です。 特に社内のオンプレサーバで動いているようなソフトウェアの場合、バージョンアップに伴う諸々の調整をそのソフトウェアを利用している各部署と行う必要があります。 そんなときに「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは?」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。 この文章はそんな時になぜバージョンアップしなければならないのかを上司や各部署のマネージャに伝えるために書きます。 ソフトウェアの有効期限は2-5年 まず、第一に、ソフトウェアというものは無限に使えるわけではなく、一定の有効期限があり、それを過ぎると徐々に動かなくなってきます。俗にいう「何もしてないのに動かなくなった問題」です。 なぜ

              ソフトウェアはなぜバージョンアップしなければならないのか - Qiita
            • Twitter障害はスクレイピングではなく“自己DDoS”が原因?

              Twitterのオーナー、イーロン・マスク氏は7月1日、Twitterでの“サービスの低下”の原因を「数百の組織がTwitterのデータを極度なレベルでスクレイピングしている」ことだとツイートしたが、原因は別のところにあるようだと、フリーランスのWeb開発者、シェルドン・チャン氏がMastodonの投稿で指摘した。 この“サービスの低下”で、多数のユーザーが投稿を読めなくなっている。マスク氏は2日、「極端なレベルのデータスクレイピングとシステム操作に対処するため」にユーザーが読める投稿数に制限を加えたとツイートした。 だがチャン氏は、異常なトラフィックの原因として、TwitterのWebアプリのバグにより、無限ループ状態でTwitterにリクエストが送信されていることを発見したと動画を添えて説明した。この動画では毎分数百件のリクエストが送信されていることが確認できる。 左の動画は、レートが

                Twitter障害はスクレイピングではなく“自己DDoS”が原因?
              • サーバー構築の練習ができるLinux学習サイトInfraAcademy(インフラアカデミー) - Qiita

                こんにちは、 InfraAcademyというLinuxやネットワークの学習サービスを作成しております、ryuと申します。 サーバー構築が練習できるLinux学習サイトInfraAcademyについてご紹介します! シミュレーターを使ってサーバー構築の練習ができる InfraAcademyでは、Linuxのシミュレーターを使ってサーバー構築の練習ができます。 今までは、VirtualBoxで学習を進めていた人も多いでしょう。 私自身もVirutalBoxでサーバーの学習をしていました。しかし、環境構築に時間が掛かります。特に、複数台の連携したサーバー構築の準備に時間がかかりました。 しかし、InfraAcademyではそのような手間は一切かかりません! 関連記事:インフラ学習におすすめのサイトInfraAcademyとは? 環境の準備が1クリック Linuxの環境準備は1クリックで完了です!

                  サーバー構築の練習ができるLinux学習サイトInfraAcademy(インフラアカデミー) - Qiita
                • GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる

                  GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年(2023年)4月に明らかにしています。 参考:GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up

                    GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
                  • 全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible

                    全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible

                      全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
                    • エンジニアは全員おうちKubernetesをやるべし【Part 1:なぜやるのか】 - Qiita

                      こんにちは。おうちKubernetesを勧めるためにやってきました。 このシリーズでは、Part 1で「なぜやるのか」、Part 2で「どうやるのか」について話します。 この記事は自宅サーバー上のKubernetesで不特定多数向けのサービスを展開することを勧めるものではなく、自分用・身内用のアプリを自宅サーバー上のKubernetesで運用することを勧めるものです。 エンジニアは全員おうちKubernetesをやるべき絶対的な理由 自己研鑽のために (鑽←この字「研鑽」と「大鑽井盆地」でしか見ない) 企業がKubernetesを採用する場合、ほとんどがEKSやGKEといったクラウド上で動作するマネージドKubernetesサービスを使用すると思います。ただ、Kubernetesであればコマンドやマニフェストファイルの書き方は共通なので、おうちKubernetesで学んだことがそのまま業務

                        エンジニアは全員おうちKubernetesをやるべし【Part 1:なぜやるのか】 - Qiita
                      • 総務省が「次世代地デジ放送」仕様策定。4K/HDR/22.2ch対応へ

                          総務省が「次世代地デジ放送」仕様策定。4K/HDR/22.2ch対応へ
                        • AWSコスト削減とリソース管理 | 外道父の匠

                          クラウド使いなエンジニアの皆様、猛暑と円安の中いかがお過ごしですか。上層部からインフラコスト削減を突きつけられてはおりませんでしょうか。 今回はおそらく初めてコスト削減についてAWSを軸に書いていきますが、考え方はどこの環境でも似たりよったりなので何かしらの足しになればと思う次第であります。 目次 長いです。ひきかえしたほうがいいぞ! コミュニティに捧げます AWSの売上 コスト削減とは 三大使命 コスト状況整理 Load Balancer 参考リンク 統合による削減 EC2 Autoscaling 参考リンク 情報整理 古いインスタンスタイプの変更 スケジュールの調整 スポットインスタンスの適用 軽量インスタンスの統合・サーバーレス化 アプリケーション処理の軽減 EC2 EBS EBSは高い 不要EBSを削除・スナップショット化 ボリュームタイプの変更 EC2 AMI NAT Gatew

                            AWSコスト削減とリソース管理 | 外道父の匠
                          • 無印「インフラゼロハウス」に行ってきた 上下水道・電気がなくても暮らせる

                              無印「インフラゼロハウス」に行ってきた 上下水道・電気がなくても暮らせる
                            • 古い技術について—SMTP現代事情つまみ食い—

                              YAPC::Hiroshima 2024

                                古い技術について—SMTP現代事情つまみ食い—
                              • 運用出来るWebアプリケーションの作り方

                                はじめに 先日、下記のようなツイートを見つけて、そういえば趣味で個人開発してたときには然程気にしてなかったけど、仕事で運用するようになって先輩たちから学んだり自分で身につけたチップスってちょこちょこあるよねー、とふと思ったので、Webアプリケーション開発に関わるものをいくつかまとめてみました。 特に体系的/網羅的という程でもないですし、最近はFWや色々な仕組みでカバーされてるものも多いですが備忘録として。 Tips 機械が読めるログを作る これは割と重要なのですが、ログは人間が読むものではなく機械が読むものです。それはZabbixだったりDatadogだったりSplunkだったりgrep/awkだったりツールは何でも良いのですが、古の時代はさておき現代ではログは機械が読めることが最重要です。 まず大前提として構造化されている必要があります。言うまでもないですが「フリーフォーマット」のログの

                                  運用出来るWebアプリケーションの作り方
                                • 「しずかなインターネット」の技術スタックを調べる - laiso

                                  ポエム特化のZenn2との噂の「しずかなインターネット」を使いはじめたので、ユーザーとしてどんな技術が使われているのかを確認していく。 sizu.me おもむろにbuiltwith.comにかけてみる。 builtwith.com ここで分かる情報はブラウザのDevTools眺めてても得られるのであまり収穫はない。 前段にCloudflareのCDNサーバーがいて Next.jsで生成されたレスポンスを返している ことがわかる。 この時点ではキャッシュのみCloudflareなのか、Pages/WorkersでNext.jsのSSRごと動かしているのかは判断できない。 認証 Set-Cookie: __Secure-next-auth.session-token=が含まれているのでNextAuth.jsを使っているのが分かる。 next-auth.js.org Emailでサインアップする

                                    「しずかなインターネット」の技術スタックを調べる - laiso
                                  • サーバーレスの次はなんなんだ

                                    はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい!」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください! メガクラウドと特化型クラウド/ハイパーバイザーのSoC化/ライセンスとクラウドベンダー/イベント駆動型API/LLM時代のAIペアプロ力/生活必需品としてのGPU・NPU/Passkey/ウェブアクセシビリティ/リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS(Function-as-a-Ser

                                      サーバーレスの次はなんなんだ
                                    • 運用に携わる人全員に見てほしい! Ops Guidesの紹介 - Qiita

                                      PagerDuty Advent Calendarの8日目! 今日はOps Guidesのお話です。 うちはこうだけど、他はどうやってるんだろう? 普段から運用に関わっていると、ふとした瞬間に「そういえば他の会社ではどういう運用をやっているんだろう?」と気になること、ありませんか? そのきっかけは「本当になんとなく」といったものから「上手くいかない運用にフラストレーションが溜まって」というどす黒いものまで色々あると思いますが、いずれにせよ「他の会社の良いところを取り入れて、自分たちの運用を改善したい」という気持ちから来ているのは間違いないでしょう。 だからこそ、いろんなミートアップに参加して発表を聞いたり、懇親会で話してみたり、Xに垂れ流されているいろんなポストを読んで事例を学ぶわけです。 ベストプラクティスを学びたい! このような取り組みはとても良いことですし、是非とも継続して情報収集し

                                        運用に携わる人全員に見てほしい! Ops Guidesの紹介 - Qiita
                                      • HTTPSレコードがRFCになりました | IIJ Engineers Blog

                                        RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお

                                          HTTPSレコードがRFCになりました | IIJ Engineers Blog
                                        • 無償版ESXiサ終!次の自宅サーバー環境どうしよう - あっきぃ日誌

                                          VMwareがBroadcomに買収され、人がバサバサ切られ、次は製品に大鉈が振られ、無償版のESXiも当たり前ながら終了となりました。 blogs.vmware.com 無償のESXiと言えば4.0か4.1くらいの頃に無償版が登場して、かれこれ15年くらい提供されてきたので、ちょっとしたサーバーインフラ好きなご家庭なら1つくらいESXi環境があったのではないでしょうか(ほんまか?) うちの自宅も2013年の自作PC導入時のタイミングから10年ちょっと無償版ESXiのお世話になってきました。本当に、今までお世話になりました。 akkiesoft.hatenablog.jp 今後はvSphereのEssentials PlusとStandardが残りつつ、買い切りモデルからサブスクリプションモデルに移行するようですが、自宅サーバーをほそぼそやるには過剰なものになると思うので、別の環境への移行

                                            無償版ESXiサ終!次の自宅サーバー環境どうしよう - あっきぃ日誌
                                          • スラッシュの有無だけでセキュリティにとんでもない大穴が空いてしまうNginxのありがちな設定ミスについて実例を踏まえて専門家が解説

                                            多機能なウェブサーバーとして2004年に登場したNginxは、2023年6月時点では業界トップシェアとなるほど人気を集めるサーバーです。そんなNginxの設定において、スラッシュを一つ付けるか付けないかの差で大きなセキュリティホールができてしまう問題について、大手パスワードマネージャーやGoogle製のツールの例をとりあげてセキュリティアナリストのダニエル・マツモトさんがブログで解説しています。 Hunting for Nginx Alias Traversals in the wild https://labs.hakaioffsec.com/nginx-alias-traversal/ Nginxの設定には、特定のURLへのアクセスをどう処理するべきかを記述できる「location」というディレクティブが存在しており、URLをサーバー内のファイルに対応させるのによく利用されています。例

                                              スラッシュの有無だけでセキュリティにとんでもない大穴が空いてしまうNginxのありがちな設定ミスについて実例を踏まえて専門家が解説
                                            • AWS、IPv4アドレスの使用に課金、1時間当たり0.005ドル。2024年2月1日から

                                              Amazon Web Services(AWS)は、サービスを外部に公開するためのパブリックなIPv4アドレスを使用する場合に、1時間あたり0.005ドルの課金を2024年2月1日から開始することを発表しました。 1時間当たり0.005ドルは1日当たりに換算すると0.12ドル、1カ月を30日とすると1カ月当たり3.6ドル。1ドル140円換算で1カ月当たり504円となります。 希少資源となるIPv4アドレス インターネットで広く使われているIPv4アドレスは数に限りがあり、12年以上前の2011年2月には管理団体からの配布が終了しています。 参考:[速報]インターネットの歴史に刻まれる、最後のIPv4割り当てセレモニーが終了 つまり、クラウド事業者やデータセンター事業者などが利用者に提供しているIPv4アドレスは、以前から事業者が所有していたか、もしくは何らかの方法で他のユーザーや事業者など

                                                AWS、IPv4アドレスの使用に課金、1時間当たり0.005ドル。2024年2月1日から
                                              • データ分析基盤まとめ(随時更新)

                                                はじめに データ分析基盤の資料を力尽きるまで追記していきます。 構成図にあるアイコンや記事の内容から技術要素を調べて記載していますが、不明分は未記載にしています。修正のコメント頂ければ助かります。 あと、この記事追加してっていう要望も歓迎いたします。 テンプレート 記事公開日 : 会社名(サービス名) データソース : データ処理 : アウトプット : 画像 URL 2025年 2024/03/14 : 株式会社エス・エム・エス(カイポケ) データソース : Amazon Aurora データ処理 : Datastream、BigQuery、dbt アウトプット : Looker Studio 2024/03/12 : 株式会社マイナビ データソース : SQL Server、Amazon S3 データ処理 : Embulk、Amazon MWAA、Apache Airflow、Snowf

                                                  データ分析基盤まとめ(随時更新)
                                                • 【15分で確認】AWSでクラウド設計する時に覚えておきたい設計原則・アーキテクチャ3選 - Qiita

                                                  何となくAWSでクラウド設計をしていませんか AWSを利用する際、多くの方が「設計」というプロセスを簡単に飛ばしてしまう傾向にあります。しかし、クラウド環境の効果的な活用には、適切なアーキテクチャ設計が不可欠です。世の中には、システム設計をする上で指針となる設計原則がいくつかあります。本記事では、以下の3つをピックアップをしてご紹介します。 本記事で取り扱う内容 ■ マイクロサービスアーキテクチャ ■ AWS Well-Architected Framework ■ The Twelve-Factor App 1. マイクロサービスアーキテクチャ マイクロサービスは、独立した小さなサービス群でソフトウェアを構築するアーキテクチャです。これにより、迅速なイノベーションと新機能の迅速な展開が可能となります。一方、モノリシックアーキテクチャは、全てが一つのサービスとして結合され、変更や障害が全体

                                                    【15分で確認】AWSでクラウド設計する時に覚えておきたい設計原則・アーキテクチャ3選 - Qiita
                                                  • めんどくさい作業を改善できるようになるには - Konifar's ZATSU

                                                    めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか?」「なぜこれをやってるんだっけ?」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状

                                                      めんどくさい作業を改善できるようになるには - Konifar's ZATSU
                                                    • AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!

                                                      はじめに お久しぶりです、iselegantです。 今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。 昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか? 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。 現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅

                                                        AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!
                                                      • SREはインフラエンジニアだけでなく、みんなの活動 - ytake blog

                                                        みなさんSREしてますか? サービスなどの品質を維持していくために切っても切り離せないSREですが、 日本でもSREという言葉が定着しつつあるかと思います。 このSREについて書いていきたいと思います。 SRE NextのCFP忘れてたのでその代わりに・・ SREってインフラですよね? 非常によくあるケース、というか多分ほとんどがこうなっていると思います。 もちろん会社としてインフラのことを指しても問題はありませんが、 SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで さらに良い活動に繋がることが多いと思います。 なんのこっちゃ、という方も多いかもしれません。 SREはエラーバジェットなどの話が必ず出てきますので、 モニタリングや監視などが必ずセットにはなっていきます。 ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、 というのが定着している場

                                                          SREはインフラエンジニアだけでなく、みんなの活動 - ytake blog
                                                        • Azure AD が発行するトークンの有効期間と考え方 (2023 年版)

                                                          Note 本記事は、2018 年公開の以下の Blog の内容が、現在の機能/技術にマッチしない内容になってきたことを踏まえ、2023 年現在の機能/技術を元に改めて考え方をおまとめしたものとなります。以前に公開した Azure AD が発行するトークンの有効期間について (2018 年公開) の記事は参考のためそのまま残し、新しく本記事を執筆しました。 こんにちは、Azure & Identity サポートの金森です。 Azure AD (AAD) は、Microsoft 365 をはじめ様々なクラウド サービスの認証基盤 (Identity Provider / IdP) として利用されています。その重要な機能としてユーザーの認証が完了したら、アプリケーションに対してトークンを発行するというものがあります。あるサービス (Teams や Exchange Online、他に Azure

                                                            Azure AD が発行するトークンの有効期間と考え方 (2023 年版)
                                                          • Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ

                                                            コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *

                                                              Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ
                                                            • AWS、高速起動にこだわった軽量なJavaScriptランタイム「LLRT」(Low Latency Runtime)をオープンソースで公開。AWS Lambdaでの利用にフォーカス

                                                              AWS、高速起動にこだわった軽量なJavaScriptランタイム「LLRT」(Low Latency Runtime)をオープンソースで公開。AWS Lambdaでの利用にフォーカス Amazon Web Services(AWS)は、実験的な実装としてサーバレス環境のAWS Lambdaで使うことにフォーカスした軽量なJavaScriptランタイム「LLRT」(Low Latency Runtime)をオープンソースで公開しました。 LLRTはRustで開発され、JavaScriptエンジンにはQuickJSを採用しています。 LLRTの最大の特徴は、現在のJavaScriptランタイムにおいて性能向上のために搭載されているJITコンパイラをあえて搭載せず、よりシンプルで軽量なランタイムとして実装することで高速に起動することにこだわっている点です。 これにより(Node.jsやDenoや

                                                                AWS、高速起動にこだわった軽量なJavaScriptランタイム「LLRT」(Low Latency Runtime)をオープンソースで公開。AWS Lambdaでの利用にフォーカス
                                                              • タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog

                                                                この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝(@sugaishun)です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか?」という会話をしたことでした。その時の私の感想は「人によって

                                                                  タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog
                                                                • 最近のCloudflare Workers - ゆーすけべー日記

                                                                  最近のCloudflare Workersについて、知らない方向けにざっくばらんに書いてみます。 連絡事項 自己紹介しておくと、僕はCloudflareのDeveloper RelationsチームにいてDeveloper Advocateをやってます。 一方で、HonoというCloudflareのみならずDenoやBun、Fastly等で動くWebフレームワークを開発してます。 Cloudflare Workersとは? 本題に入る前に、そもそも「Cloudflare Workersとは?」を簡単に紹介しておきます。 Cloudflare WorkersとはCloudflareのエッジで動くサーバーレス環境です。 基本的にJavaScript/TypeScriptでアプリケーションを書きます。 V8というJavaScriptエンジンの上でアプリを動かすのですが、これはWebブラウザのGo

                                                                    最近のCloudflare Workers - ゆーすけべー日記
                                                                  • コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita

                                                                    最近実際に開発現場にコンテナを導入してきた経験から、公式ドキュメントに記載されているベストプラクティスに実際どうなんだということを言ってみようと思います。公式に書いてあることを間違ってると指摘という意図はありません 発言は個人の見解に基づくものであり、所属組織を代表するものではありません。 2023/12/3更新: 燃えかけてるのでタイトルを変えました。 補足: こちらの環境は下記を想定しています。 Java CICD/本番環境イントラネット内に整備 WF開発 マルチステージ・ビルドを使う マルチステージビルドの目的 公式ドキュメントには、下記のように記載があります。 マルチステージ・ビルド は、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。 つまり、最終イメージの容量を減らすことが目的であって、その一つの手段としてマルチステージビルドを進めて

                                                                      コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita
                                                                    • 続、Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ

                                                                      先週の火曜日、3月12日に始まったPublickeyへのDDoS攻撃は今週日曜日、3月18日日曜日の早朝を最後に収まったようです。この記事執筆時点でPublickeyのサーバは平常に戻っています。 この間、読者や広告を掲載いただいているお客様や代理店様にご不便やご心配をおかけし申し訳ありませんでした。 DoS攻撃とは、大量のトラフィックをWebサーバなどに浴びせることでサーバを応答不能にしてしまう攻撃のことです。 前回の報告「Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」の後、さらにいくつか対策を講じましたので、この記事では前回の報告以後の経緯と講じた対策を記したいと思います。 また、前回の報告では「DoS攻撃」と書きましたが、その後Publickeyのサーバをホスティングしているさくらインターネットのサポート担当の方から、今回の攻撃は分散した箇所から攻撃を受けていると

                                                                        続、Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ
                                                                      • JR東日本システム障害すべて復旧 一時モバイルSuicaなど不具合 | NHK

                                                                        24日未明、JR東日本でシステム障害が発生し、券売機などでクレジットカードが使えなかったり、「モバイルSuica」でアプリでのチャージができないなどの不具合が起きたりしましたが、会社は午後1時ごろまでにすべて復旧したと発表しました。 JR東日本によりますと、24日午前0時半すぎにシステム障害が発生し、駅の構内や駅ビルの店舗、それに駅の券売機やみどりの窓口でクレジットカードを使うことができなくなりました。 復旧作業を進めた結果、会社は午前10時15分ごろに復旧したと発表しました。 その後も運賃の支払いなどを行う「モバイルSuica」でアプリでのチャージができなかったり、ネット上で指定席などを予約する「えきねっと」が利用できなかったりする不具合が続いていました。 この不具合についてJR東日本は、発生から12時間余り後の午後1時ごろに復旧し、システム障害はすべて解消されたと発表しました。 JRに

                                                                          JR東日本システム障害すべて復旧 一時モバイルSuicaなど不具合 | NHK
                                                                        • Google Cloud案件を1年半程度経験してみてAWSと比較しながら違いを整理してみた - NRIネットコムBlog

                                                                          本記事は 【Advent Calendar 2023】 15日目の記事です。 🎄 14日目 ▶▶ 本記事 ▶▶ 16日目 🎅 はじめに 想定している読者 一覧 まとめてみて 参考 はじめに クラウド事業推進部の小野内です。昨年5月にキャリア入社してから早1年半以上が経ちました。 入社以降、AWS、Google Cloud のデータ分析基盤の開発・運用に関わっておりますが、現在はGoogle Cloud メインでやってます。 試行錯誤の毎日ですが、Google Cloud案件をどんどん盛り上げていきたい所存です。 1年ほど前の投稿記事では、 Google Cloudの学び方について触れましたが、本記事ではGoogle Cloud案件を1年半程度経験してみて、 AWSと比較しながら、Google Cloudの主要なサービスについて、違いを整理しました。 想定している読者 AWS案件に半年以

                                                                            Google Cloud案件を1年半程度経験してみてAWSと比較しながら違いを整理してみた - NRIネットコムBlog
                                                                          • DNSでHTTPS ※ただしDNS over HTTPSではない

                                                                            執筆者:IIJ ネットワーク本部 アプリケーションサービス部 DNS技術課 山口 崇徳 2023年11月、HTTPSレコードがRFC9460として標準化されました。 HTTP/3を支える技術のひとつで、WebサーバのDNSへの登録方法も変わります。 CNAME + MX + α の機能も備えています。 DNS / Web / ファイアウォール運用者はぜひご覧ください。

                                                                              DNSでHTTPS ※ただしDNS over HTTPSではない
                                                                            • JR東日本のシステムが復旧、電気工事で誤って切ったブレーカーが原因か

                                                                              JR東日本は2023年6月24日、午前0時37分ごろから発生していたシステム障害は午後1時ごろにすべて復旧したと発表した。JR東日本によれば「詳しい原因は調査中だが、屋内電源設備の工事の際に誤って予定していなかったブレーカーを切ってしまったためと思われる」(コーポレート・コミュニケーション部門)という。 障害発生当初は、みどりの窓口や発券機でのクレジットカード利用ができなくなった。また交通系ICカード「Suica(スイカ)」をスマートフォンなどで使える「モバイルSuica」や、インターネット切符予約サービス「えきねっと」にログインできない状態だった。 交通系ICカード「PASMO(パスモ)」でも同日午前0時30分ごろに電源トラブルによる障害が発生し、午後1時14分ごろに復旧した。障害発生中はモバイルPASMOの利用や、ICカードの再発行/払い戻しができなかった。 関連記事 JR東日本でシス

                                                                                JR東日本のシステムが復旧、電気工事で誤って切ったブレーカーが原因か
                                                                              • 本当のAWS基礎 昭和~平成~令和の時代の変遷システムの変化と今昔物語 - Qiita

                                                                                内容 社内でAWS知らない人でもこれだけは覚えていてほしいという動画を作成して欲しいとリクエストあり。その内容を資料化したものです。小学生の子供に説明してみましたがになんとなくAWSが分かったと言っていたので今回は結構分かりやすくまとめられたと思います。 システムを構築する時 システムを構築する際、サーバやネットワークなどのインフラが必要になります。昭和の時代は物理サーバを買ってきてラックマウントしてネットワークに接続してと物理的な作業が多く発生していました。 その後、物理サーバの上に仮想的なサーバを作成できる仮想化技術の発展により、仮想サーバが主流となりました。最初に物理サーバを用意して、仮想化基盤を構築する必要があります。仮想化基盤構築後は、新しいシステムを作りたい場合はすぐに仮想サーバの準備を行うことができ、物理環境の時と比較すると大きな進展がありました。 仮想化基盤を自社で構築する

                                                                                  本当のAWS基礎 昭和~平成~令和の時代の変遷システムの変化と今昔物語 - Qiita
                                                                                • AWS、IPv4アドレスへの課金が今月からスタート。1カ月約500円

                                                                                  Amazon Web Services(AWS)は、サービスを外部に公開するためのパブリックなIPv4アドレスに対して、1個1時間あたり0.005ドルの課金を今月(2024年2月)からスタートしています。パブリックなIPv4アドレスへの課金は、Amazon EC2、Amazon RDSを含むAWSの全てのサービスが対象です。 1時間当たり0.005ドルは1日当たりに換算すると0.12ドル、1カ月を30日とすると1カ月当たり3.6ドル。1ドル140円換算で1カ月当たり504円です。 パブリックなIPv4アドレスへの課金は昨年(2023年)7月に発表されており、予定通りに実行されたことになります。 参考:AWS、IPv4アドレスの使用に課金、1時間当たり0.005ドル。2024年2月1日から 最大手のAWSがIPv4有料化に踏み切った意味 インターネットで広く使われているIPv4アドレスは、1

                                                                                    AWS、IPv4アドレスへの課金が今月からスタート。1カ月約500円