ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
![AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege](https://cdn-ak-scissors.b.st-hatena.com/image/square/3f614a2e531536913b84aeed027e675dd1222094/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F38ed037ac1014e2c98f16eeab2c8b79d%2Fslide_0.jpg%3F31066959)
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
しばたです。 昨年10月にGoogle(Gmail)および米国Yahoo!においてスパム対策の強化がアナウンスされました。 この件に関してつい先日まで他人事でいたのですが、実は全然他人事では済まないことが発覚し突貫で知識を仕入れています。 アナウンスに対する具体的な対応策についてはこちらのZennの記事を見れば全部わかる感じです。 最高ですね。 また、メール送信にAmazon SESを使っている場合はAWSのブログを確認すると良いでしょう。 「これらの記事を読み解けば万事解決!」という感じではあるのですが、私自身が学んだなかで予め知っておくと良さそうに思えた点がいくつかありました。 本記事ではその辺を共有するのと、実際にAmazon SESの環境を作って動作確認をしたのでその結果も合わせて共有します。 はじめに覚えておくと良い基礎知識 Zennの記事でも詳細な解説がありますが、個人的に「最
こんにちは、アルダグラムのSREエンジニアの okenak です 今回は AWS ClientVPN を導入したことで、社内の運用業務の効率化とセキュリティの強化を達成した事例を紹介したいと思います。 背景 2019年の段階では社員数が12名程度だったこともあり、社内システムのアクセス制御にAWSのセキュリティグループを利用してオフィスIPやリモート接続先IPを解放することで対応を行っておりました。 2023年には社員数が80名になっており、インバウンドルールが40を超えセキュリティグループが穴だらけという状態になっており、社員数増加に伴うIP制限更新作業による管理コストの増大とセキュリティ上のリスクが問題になってきたため、AWS ClientVPNを導入することに踏み切りました。 AWS ClientVPNについて VPNに関して他社のサービスとも比較しましたが以下の点が推しポイントでし
はじめに このチュートリアルでは、『証明書に紐付いたアクセストークン』を活用して Amazon API Gateway 上に構築した API をこれまで以上に安全に保護する方法を紹介します。 OAuth アクセストークンが一度漏洩すると、攻撃者はそのアクセストークンをもって API にアクセスできます。従来のアクセストークンは電車の切符のようなもので、一度盗まれたら誰でも使えてしまいます。 この脆弱性はアクセストークンと同時にアクセストークンの正当な保有者である証拠も併せて提示することを API 呼出者に要求することで軽減することができます。その証拠は proof of possession と呼ばれ、よく PoP と短縮されます。使用時に PoP を必要とするアクセストークンは、搭乗時にパスポートの提示も併せて要求される国際線の航空券に似ています。 RFC 8705 (OAuth 2.0
複数のクラウドサービスを利用している(マルチクラウド)など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
ベルリンのしがひです。COVID-19渦はヨーロッパにも広がり、いくつかの自治体で地域封鎖などの緊急防疫が実施されています。 日本では通勤時の混雑と密集がハイリスクであること、また安倍首相が今週からの学校閉鎖を要請するという発表を行ったことで会社員の在宅勤務の必要性がますます高まり、Slack、Zoomといったリモートワークツールへ注目が集まっています。 しかしながらリモートワークはコミュニケーションに使用するツールのみで事足りるものではなく、業務システムやドキュメントへのアクセスが安全に確保されていることが必要で、実際のところ、全社員にこういったリモートアクセス環境を用意することへのハードルが高いのではないでしょうか。 今回はオンプレ、クラウドにあるシステムへのリモートアクセスを即興で構築する方法を実践します。差し迫ったリモートワーク対応のヒントになればと思います。 VPNを構築している
1passwordのアイテム編集画面で、フィールドタイプを眺めててふと思った。「ワンタイムパスワードってあるけど、これ、AWSで多要素認証するときの『仮想MFAデバイス』に使えるのでは」と。結論から言えば、使えた。快適。でもこれは多分「人をダメにするナントカ」的な快適さだ。やっちゃいけないやつだ。 AWSでは、AWSアカウントの管理者であるrootユーザー(メールアドレスでログインする人)と、利用者であるIAMユーザー(ユーザーIDでログインする人)のどちらでも、多要素認証(MFA:Multi-Factor Authentication)を設定して認証を強化できる。 認証方法はパスワード認証+ワンタイムパスワード(当人が知っていること+当人が持っているもの) ワンタイムパスワードの生成には、専用のデバイスであるU2FセキュリティキーやハードウェアMFAデバイス、スマホアプリである仮想MFA
こんにちは、生産性向上チームの五十嵐(@ganta0087)です。 今回はAWSアカウントの管理についてのお話です。 AWSアカウントをみなさんの組織ではどのように管理されているでしょうか? シングルアカウントで運用していると、人やチームが増えて規模が大きくなってきたときに権限管理が中央集権的になり、管理者への負担が増大してしまいます。また、新規ユーザーの登録だけでなく、退職時の削除漏れにも注意が必要です。利用者側としても管理するパスワードが増えるのは避けたいです。 そこで、生産性向上チームではマルチアカウント構成によるシングルサインオン(以下SSO)とチームに委譲できる権限管理のしくみを作ることでこれらの問題を解決し、社内でAWSを活用しやすくなるようにしました。 サイボウズには社員のアカウント情報を管理しているActive Directory(Azure AD)があります。今回はそのA
シンジです。sshを利用してサーバーへアクセスする際、IDとパスワードでrootにダイレクトアクセスさせてるケースもままあるでしょうが、監査も通らないし乗っ取りリスク高すぎ問題なので辞めたいところです。クラウドを日常的に利用する方々の場合、通常は証明書認証によってサーバーログインを行っていると思います。証明書ファイルが次々と増えていく問題、証明書ファイルを手に入れれば多くの人がサーバーにログインできちゃう問題は目をつぶるしかないのか。 そこでエンプラなどでは、「踏み台サーバー」を作って、そこでアクセス権限をコントロールすることで、サーバーログインへの統制を図るわけですが、第一踏み台から第二踏み台へそして第三踏み台とかいう絶望も現実的に存在している実状です。そもそも、エンプラが踏み台サーバーを自前で作るわけがなく、そういう製品を購入して作ってもらう、はい数千万円、保守費毎年よろしくみたいな世
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く